Hi, I started to use the DxlObject/struct Combo technique to define my own types. OK. Does someone can tell me now how to integrate these new type in the Sodius DXL Debugger ? Own types variables do not appears and I can't even define an expression that use these variable. Any tips or DXL Debugger configuration techniques ? Thanks in advance. Joseph. jaracic - Fri Jun 12 08:42:12 EDT 2015 |
Re: DXL Debugger and Own Types Sodius DXL Editor has no way of evaluating your DXLObjects since it doesn't know how many fields are in it or what their types are. I suggest keeping some variables around to hold the values of your DXLObject members so you can see what they are. I take a similar approach when using the DXLObject type. Of course, those extra variables are removed before the DXL program is delivered. They are only temporary. |
Re: DXL Debugger and Own Types Hello Joseph A DxlObject is nothing else but a skip list created by createString(). So you can use a command like Skip skpDebugHelp = (Skip addr_(msDxlObject)); And then you can get access by the dxl-debugger Best regards Wolfgang |
Re: DXL Debugger and Own Types Hi, Thanks for your reply, I'm convinced there is a way to do that without modifying the DXL code. I'm wondering if there is a way to "extent" de DXL Debugger in some ways (For example by providing some extra DXL Code for debugging, as it already exists it seems to explore the content of a Skip list (SkipContents function If I remember). May be it time to contact Sodius Support. Regards. Joseph |
Re: DXL Debugger and Own Types jaracic - Thu Jul 02 04:29:28 EDT 2015 Hi, Thanks for your reply, I'm convinced there is a way to do that without modifying the DXL code. I'm wondering if there is a way to "extent" de DXL Debugger in some ways (For example by providing some extra DXL Code for debugging, as it already exists it seems to explore the content of a Skip list (SkipContents function If I remember). May be it time to contact Sodius Support. Regards. Joseph Hi > I'm convinced there is a way to do that without modifying the DXL code. I'm convinced that there is no way > I'm wondering if there is a way to "extent" de DXL Debugger in some ways (For example by providing some extra DXL Code for debugging, as it already exists it seems to explore the content of a Skip list (SkipContents function If I remember). > May be it time to contact Sodius Support. The question is if they want to investigate time in further developement. > SkipContents Yes this is the routine and the best "next step" is to provide an interface that someone can add his own routines. But think about. The debugger is out and has been sold.New functions may result in additional fees for an update and I'm not shure that sodius will have an easy pay back. What do you think, how many dxl developers exists around the world using a debugger? And how many do know SkipContents? Best regards Wolfgang
|
Re: DXL Debugger and Own Types Wolfgang Uhr - Thu Jul 02 06:36:50 EDT 2015 Hi > I'm convinced there is a way to do that without modifying the DXL code. I'm convinced that there is no way > I'm wondering if there is a way to "extent" de DXL Debugger in some ways (For example by providing some extra DXL Code for debugging, as it already exists it seems to explore the content of a Skip list (SkipContents function If I remember). > May be it time to contact Sodius Support. The question is if they want to investigate time in further developement. > SkipContents Yes this is the routine and the best "next step" is to provide an interface that someone can add his own routines. But think about. The debugger is out and has been sold.New functions may result in additional fees for an update and I'm not shure that sodius will have an easy pay back. What do you think, how many dxl developers exists around the world using a debugger? And how many do know SkipContents? Best regards Wolfgang
I wrote the DXL core of the DXL Debugger and I can tell you for sure, that there is no easy way to extend the debugger to show these variables without modifying the DXL code. The problem here is, that the debugger modifies the DXL code itself to make the variables known to the evaluation engine. And without that modification the debugger will not know about those variables. Of course you can modify the source code to make the variables known to the debugger - but then you are back to modifying the source code. One possibility you could explore here: - Since the debugger executes the evaluation inside an 'eval_' context (child of the program context) you will not have access to the DXL context in which your types are declared. However you will have access to the top level context. So any library that you register with "evalTop_" can be accessed from expressions inside the debugger. Knowing about the internals of your classes you could have your own evaluation functions - still without extra code to make the variables known to these functions it will not work. Only way out here is, that Sodius would give the possibility to extend the list of known types (e.g. recognize the struct keyword inside the DXL to add the type to the list of known types). Regards, Mathias |
Re: DXL Debugger and Own Types Mathias Mamsch - Fri Jul 03 20:07:46 EDT 2015 I wrote the DXL core of the DXL Debugger and I can tell you for sure, that there is no easy way to extend the debugger to show these variables without modifying the DXL code. The problem here is, that the debugger modifies the DXL code itself to make the variables known to the evaluation engine. And without that modification the debugger will not know about those variables. Of course you can modify the source code to make the variables known to the debugger - but then you are back to modifying the source code. One possibility you could explore here: - Since the debugger executes the evaluation inside an 'eval_' context (child of the program context) you will not have access to the DXL context in which your types are declared. However you will have access to the top level context. So any library that you register with "evalTop_" can be accessed from expressions inside the debugger. Knowing about the internals of your classes you could have your own evaluation functions - still without extra code to make the variables known to these functions it will not work. Only way out here is, that Sodius would give the possibility to extend the list of known types (e.g. recognize the struct keyword inside the DXL to add the type to the list of known types). Regards, Mathias Hi Mathias
That's in fact my opinion too and the solution is to define an interfaces for Routines like "SkipContents", so that you can add your own "expression routines". The question for sodius is: Are there enough customers which are willing to pay for it. I for myself would go to my cost center responsible and I'm pretty shure to get a go for it. But this is only one license. I cannot ask for the whole project. Best regards Wolfgang |
Re: DXL Debugger and Own Types Mathias Mamsch - Fri Jul 03 20:07:46 EDT 2015 I wrote the DXL core of the DXL Debugger and I can tell you for sure, that there is no easy way to extend the debugger to show these variables without modifying the DXL code. The problem here is, that the debugger modifies the DXL code itself to make the variables known to the evaluation engine. And without that modification the debugger will not know about those variables. Of course you can modify the source code to make the variables known to the debugger - but then you are back to modifying the source code. One possibility you could explore here: - Since the debugger executes the evaluation inside an 'eval_' context (child of the program context) you will not have access to the DXL context in which your types are declared. However you will have access to the top level context. So any library that you register with "evalTop_" can be accessed from expressions inside the debugger. Knowing about the internals of your classes you could have your own evaluation functions - still without extra code to make the variables known to these functions it will not work. Only way out here is, that Sodius would give the possibility to extend the list of known types (e.g. recognize the struct keyword inside the DXL to add the type to the list of known types). Regards, Mathias On the other hand: evalTop_ is a very nice idea indeed. Some routines in the background will simplifiy your debugging life, I think. |